Intro

회사에서 유지보수를 하다가 끔찍한 프로젝트를 보게 되었다. 변수명과 클래스 명은 모두 1,2,3 혹은 A, B, C로 구분되어 있었다. 이런 이유 때문에 유지보수 하는 일이 너무 힘들었다. 그래서 어떻게 하면 나는 이런 코드를 짜지 않을 수 있을까? 어떻게 하면 이 코드를 좋은 코드로 바꿀 수 있을까?라는 의문점이 생겼다. 그래서 미루고 미뤄왔던 클린코드를 읽어보려고 한다.

코드가 존재하리라

요즘 기술이 발전함에 따라 코드를 자동으로 생성해주는 기술들이 생겨나기 시작했다. 그럼에도 저자는 코드가 사라질 가망이 없다고 한다.

"궁긍적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 
요구사항에 더욱 가까운 언어를 만들 수도 있고, 요구사항에서 정형 구조를 뽑아내는 도구를 만들 수도 있다. 
하지만 어느 순간에는 정밀한 표현이 필요하다.
그 필요성을 없앨 방법은 없다.

그러므로 코드도 항상 존재하리라."

나쁜 코드

80년대 후반 킬러 앱 하나를 구현한 회사를 이야기하면서 시작한다.
회사가 망했는데, 그 원인은 바로 나쁜 코드 탓이었다.
나쁜 코드에 발목이 잡혀 고생하는 것을 고행(Wading)이라 부른다.

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 
우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 
다시 돌아와 나중에 정리하겠다고 다짐했었따.
물론 그때 그 시절 우리는 르블랑의 법칙(Leblanc's Law)을 몰랐다.

나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.
그러다 팀은 재설계를 요구한다.
새로운 프로젝트를 시작하기 때문에 모두가 합류하고 싶어한다.
나도 그렇다… 처음부터 시작해 진정으로 아름다운 작품을 창조할 기회니까.
재설계는 10년이 넘을 수도 있다.
그러다 보면 원년 멤버는 사라져있고, 새로운 팀원들이 새 시스템을 설계하고자 나선다.
즉, 깨끗한 코드를 만드는 노력은 전문가로서 살아남는 길이라는 사실이다.

자신이 의사라 가정하자.
어느 환자가 수술 전에 손을 씻지 말라고 요구한다.
시간이 너무 걸리니까.
확실히 환자는 상사다.
하지만 의사는 단호하게 거부한다.
왜? 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까.
환자 말을 그대로 따르는 행동은 (범죄일 뿐만 아니라) 전문가답지 못하니까.

프로그래머도 마찬가지다.
나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
  • 중요한 워딩 : 가독성, 명쾌한 추상화, TDD, 주의

-> 중복을 피하라, 한 기능만 수행하라, 제대로 표현하라, 작게 추상화하라

보이스카우트 규칙

"캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라"

지속적인 개선이야말로 전문가 정신의 본질이다.

결론

이 책을 통해 여러 방법을 익히고, 느껴야한다.
그렇게 체득한 후에 개선점을 생각하고, 나의 가치를 올릴 수 있는 방향으로 나아가야겠다.